Field
Embodiments of the present invention generally relate to software-defined networking (SDN) devices. In particular, embodiments of the present invention relate to scalable SDN devices having ports/network interfaces mapped to cardinal flow processing (CFP) units.
Description of the Related Art
With network traffic increasing rapidly day by day, it is becoming harder for hardware based switches or network security devices to provide required scalability. In order to overcome limitations of existing hardware-based switches/network security devices, SDN devices have been proposed for providing scalable and fast processing of network packets. Existing SDN devices, such as SDN switches, are replacing traditional routers and switches in several high-end applications including emerging cloud and datacenter environments where a large amount of traffic needs to be monitored and filtered. In a typical implementation of SDN, an Internet Protocol (IP) packet needs to traverse through different network functions or security checks before the packet is forwarded to the final destination. SDN is an approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality, which is done by decoupling the operating system that makes decisions about where traffic is sent (the control plane) from the underlying hardware systems that forwards traffic to the selected destination (the data plane).
In most cases, these SDN devices, which may also be interchangeably referred to as SDN switches hereinafter, are relatively commoditized units using Ternary Content-Addressable Memory (TCAM)-based platforms that have been enabled to make use of programmed flow statements to perform packet forwarding decisions, either in lieu of or in concert with forwarding tables generated by traditional routing and switching protocols.
The first-generation of these SDN switches, though economical to manufacture, have significant limitations in terms of traffic volume that these switches can handle. Such SDN switches maintain a table having multiple entries where each entry signifies different properties of the packet that need to be checked in a typical single-table pipeline architecture used by these SDN switches before the SDN switches can make the forwarding decision. The first generation SDN switches, which can be single-TCAM switches, have acceptable forwarding properties when evaluating a small number of fields, such as a Media Access Control (MAC) address or IP address in a table. However, such SDN switches lack scalability, particularly when the number of entries in a table that needs to be checked before making the forwarding decision increases. While single-TCAM switches can have acceptable forwarding properties when evaluating a small number of fields in a flow table, if the flow table entries have a large number of fields (as is the case in the OpenFlow protocols, including, but not limited to Open Networking Foundation (ONF), “OpenFlow Switch Specification,” Version 1.5.0 (Protocol version 0x06), Dec. 19, 2014 (hereafter, the “OpenFlow Protocol,” which is hereby incorporated by reference in its entirety for all purposes), are now being used. For example, when using the OpenFlow Protocol, which defines a minimum of thirteen fields within a single-table pipeline, the number of supported flow-table entries by these SDN switches is dramatically reduced. Even increasing the size of the TCAM is not a practical solution as TCAMs have finite data paths, and increasing the size can result in significant performance bottlenecks for the network security devices, such as SDM switches.
In order to overcome the above-mentioned limitations, use of multi-table pipelines has been proposed, in which Field Programmable Gate Arrays (FPGAs) and memory or Dynamic Random Access Memory (DRAM) can be used to conduct high-performance searches of simple tables, and where microcode within the FPGAs can be used to discretely mimic TCAM search functions on a limited basis. However, this forces the use of multi-table packet processing pipelines as compared to the simplicity of single-table pipelines supported by true TCAMs.
To further overcome limitations and provide scalability, second-generation SDN switches have been proposed, which use dedicated hardware that is intended to overcome size and performance limitations associated with first generation (single-TCAM) switches. Most of the existing second-generation SDN switches use larger TCAMs, FPGAs+ memory, or both, wherein these switches have to maintain a tradeoff between performance and programmable flow table size. For instance, ZNYX ZX1200-SDN and B2-SDN switches claim to support 300K OpenFlow Protocol programmed flow statements, but are limited to an aggregate performance of about 35 Gbps. Noviflow Noviswitch line claims support for 100-240 Gbps and incorporates an ‘Optimized TCAM’ architecture but these performance values can only be attained with multi-table pipelines.
These existing solutions, along with others, are therefore do not meet the performance levels required by dedicated hardware solutions for high-end applications, such as cloud and datacenter environments, particularly for network security functions. In a majority of use-cases, such datacenter environments and clouds require dedicated SDN switch solution support for around 200K flows even when using single-table pipelines, aggregate switching performance of 640 Gbps based on support of a 16 spine spine-leaf architecture at 10 Gbps per connection. Also, as the number of network security functions/services that need to be performed on an IP packet before making a forwarding decision increases, performance of existing network security devices may be further degraded. However, it has been observed that it is not required by the network security devices to perform all the security functions/services in similar manner for all the incoming packets. There may be some packets that require only selected security functions/services, for which the routing decisions can be made based on the selected security function/service itself. Performance of SDN devices can therefore be improved by selectively performing only the required security function/service on the packet before making the routing/forwarding decision.
There is therefore a need for systems and methods for providing scalable and high performance SDN devices that enable selective packet steering capabilities to a network security device for selectively forwarding packets to flow through a network service. Systems and methods are also required for providing maximum programmable flow capacity, high throughput performance, and flexible pipeline programmability.